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Abstract 



This paper presents MyZone, a private online social network for relatively small, closely- 
knit communities. MyZone has three important distinguishing features. First, users keep the 
ownership of their data and have complete control over maintaining their privacy. Second, 
MyZone is free from any possibility of content censorship and is highly resilient to any single 
point of disconnection. Finally, MyZone minimizes deployment cost by minimizing its com- 
putation, storage and network bandwidth requirements. It incorporates both a P2P architecture 
and a centralized architecture in its design ensuring high availability, security and privacy. A 
prototype of MyZone was deployed over a period of 40 days with a membership of more than 
one hundred users. The paper provides a detailed evaluation of the results obtained from this 
deployment. 
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1 Introduction 



Online social networks (OSNs) are typically designed as centralized systems, where central servers 
provide both storage and connectivity services. The key advantages of this design include high 
availability of user profiles (irrespective of whether they are online or not), ease in establishing 
online interconnectivity among users, and ease of management in terms of enforcing providers' 
security and privacy policies. Indeed, all popular OSNs such as Facebook, Twitter and Linkedin 
have been built as centralized systems. However, as some of the recent events have shown [TTllSlfTOl 
[IIl[l2l[I21, users of these systems lose control of their privacy and ownership of their data, and the 
systems themselves are prone to censorship and complete disconnection. Furthermore, building a 
centralized server incurs large resource and management cost. 

In this paper, we propose My Zone, a private online social network for facilitating social com- 
munication using standard social network features among the members of a relatively small, closely- 
knit community. My Zone provides three distinguishing characteristics. First, users keep the owner- 
ship of their data and have complete control over maintaining their privacy. In particular, users are 
not resigned to store their profiles at a central server owned by OSN providers, and neither are they 
required to store them in unknown storage nodes typically determined by DHT-style techniques in 
P2P networks. Instead, users in My Zone store their data on their own devices and replicate them 
on the devices of the users that they trust. My Zone provides support for efficient propagation of 
profile updates to all rephcas, and maintains the privacy and integrity of user data despite being 
replicated in multiple independent administrative domains. 

Second, My Zone is free from any possibility of content censorship. Users own their content, 
and no single entity or a small group of entities can conspire to block them. Furthermore, My Zone 
is highly resilient to any single point of disconnection. It remains operational even when it is 
under active assault from a single entity or a small group of entites trying to shut it down. Finally, 
My Zone employs a (mostly) decentralized architecture. While a centralized server is needed for 
initial user registrations and (sometimes) to locate friends' profiles, the bulk of communication 
takes place in a P2P fashion, and most importantly, the centralized server is not used for storing 
user profiles. Hence, computation, storage and network bandwidth requirements of centralized 
servers are drastically reduced. This significantly reduces the resource or maintenance cost of 
deploying My Zone. 

While My Zone can certainly be used for building a large-scale OSN, our focus in this paper is 
to facilitate private OSN for relatively- small (hundreds to thousands of members) and closely-knit 
communities. Friends who do not wish to expose their data to third-party social network providers 
such as Facebook or Google-i- can form their own private social networks using MyZone. Also, 
My Zone is very well suited for building communities that wish to keep their data confidential, 
yet continue to organize, e.g., an OSN for high school students, parents and teachers to facilitate 
social as well as academic interactions among themselves. MyZone is appropriate for organizing 
activities such as democratic advocacy in countries where the state may easily deny access to 
traditional social networks by cutting off Internet access to the servers of those networks. Figure 
[T] illustrates the shortcomings of conventional OSNs and how our private social network fits in the 
overall picture. 

MyZone incorporates both a P2P architecture and a centralized architecture in its design. It 
employs an unstructured P2P network for storing user profiles. A user's profile is stored on his/her 
device and mirrored on the devices of a few other users based on the user's trust. MyZone ensures 
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Figure 1: Depiction of conventional OSNs' deficiencies. 

that user profile is only accessible to the user's friends and any updates such as writing on the 
wall are quickly propagated to all mirrors. In addition, MyZone utilizes a central server for user 
registration and for storing some important meta information. A prototype of MyZone has been 
implemented. The paper reports the results of an extensive deployment of this prototype that 
included more than one hundred members over a period of 40 days. 

The rest of this paper is organized as follows. Section |2] reviews some important related works 
and Section [3] states the system assumptions and challenges in building MyZone. Section |4] de- 
scribes the detailed system design and Section [5]describes the prototype deployment and evaluates 
MyZone based on the results of this deployment. Finally, Section |6] concludes the paper. 

2 Related Work 

There have been several attempts at P2P social networks, motivated by the desire to achieve user 
privacy. Safebook [6] is a decentralized and privacy-preserving OSN that provides two types of 
overlays: a set of concentric structures called matryoshkas created around each node to provide 
data storage and communication privacy; and a P2P substrate providing lookup services. Ma- 
tryoshkas are built using the idea of selecting trusted friends as mirrors. There are several issues 
with the design of Safebook. First, a node can join Safebook only by invitation. Second, the 
reachability of a user on Safebook depends on the number of mirrors. Third, offline messages like 
wall posts are not accessible until the user comes back online and publishes those updates. Fourth, 
Safebook is dependent on a third-party P2P system to implement a DHT to find entry points for 
each node. Another serious problem with Safebook is that it does not address friend revocation 
that is an inherent part of any OSN. Finally, using the overlay matryoshkas would result in longer 
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paths on the IP infrastructure yielding poor performance. 

A high level description of another P2P OSN called PeerSoN is provided in IH. PeerSoN has 
a two-tier architecture: a look up tier that uses DHT and a second tier that consists of peers and 
contains user data. It is implicitly assumed that the users are connected most of the time, perhaps 
through different devices and from different locations. It is not clear if and how these devices 
would be synced with each other. Offline messages are stored on a DHT, which means scalability 
may be an issue here. Furthermore, user profiles are not replicated, which means a user's profile is 
not accessible if she is offline. Finally, friend revocation is not considered as a functionality of the 
system. 

Vis-a-Vis[[T3| is an OSN design that uses Virtual Individual Servers (VIS) as personal virtual 
machines running in a paid compute facility. In Vis-a-Vis, a person stores her data on her own 
VIS, which arbitrates access to that data by others. VISs self-organize into overlay networks 
corresponding to social groups. Vis-a-Vis is designed so that it can interoperate with existing 
OSNs. The main issue with this system is that users have to pay for a VIS and in many cases take 
charge of maintenance of their own VIS. 

Cuckoo lfT6ll is a microblogging decentralized social network that uses a centralized OSN only 
as backup and as a byproduct saving bandwidth costs and reducing downtime while performing 
equally well. Cuckoo organizes user clients into a structured P2P overlay using Pastry. Cuckoo 
does not provide any encryption and can only be applied to microblogging services like Twitter 
with very limited functionalities. 

In addition, a variety of past and ongoing projects on P2P social networking include DiasporadUl, 
The Appleseed Project[|2l|, and Peerbook[3| that all require an online server. Obtaining a publicly 
accessible server is not free of charge, and needs regular monitoring and maintenance on behalf 
of the user. All P2P OSNs to date assume public IP addresses for peers and they do not address 
the problem of NAT traversal. Furthermore, with a exception of a few, the majority of these works 
have not been implemented while none have been thoroughly evaluated in real world deployments. 

3 System Model 

We begin by making the following assumptions about the system and network connectivity. Partic- 
ipating devices can be desktops, laptops or smartphones with network connectivity either through 
Ethernet or wireless. Although each device can be behind any kind of firewall or NAT, a reason- 
ably small number of devices should be able to obtain public IP addresses. Out of all those devices 
with public IP addresses, at least one, should have two network connections, i.e., dual homed, with 
different public IP addresses. Furthermore, a couple of those participating devices with public 
IP addresses, should be able to host databases that serve other peers. We assume there exists a 
functioning IP infrastructure at all times, even though it may be partitioned to some extent either 
intentionally or due to unpredictable outages. 

Given these assumptions, our design goals are the following: (1) My Zone should support all 
primary functionalities of a conventional OSN like Facebook, including the ability to establish and 
revoke friendships, sharing contents and comments with friends at different levels, and participat- 
ing in discussions; (2) It should preserve user privacy by ensuring that users own their own data, 
and no central authority or third party can access user information without explicit permission 
from the user; (3) It should be highly resilient in face of malicious attacks as well as infrastruc- 
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ture failures caused by unpredictable causes, possessing self healing properties by automatically 

reconciling the states after connection has been restored; (4) It should tolerate a high rate of churn 
due to mobile users, and seek to provide near 24/7 availability of user profiles (best effort); and 
(5) The system should be designed to be minimally demanding of the limited resources of portable 
devices, and should incorporate power/resource management techniques. 

We choose a decentralized P2P model based on user trust to realize the above design goals 
of our system, rather than a traditional client-server model. Users will own their own social data 
and store it on their own machines, including their own desktops, laptops, and mobile devices, or 
on the devices of others they trust, rather than storing their social data on an untrusted third-party 
server or on a DHT. Thus, friends may act as mirrors for each other, thereby allowing updates to 
a user's profile even if the user's primary machine is not currently accessible, as may be the case 
for mobile devices. In order to protect communications and authenticate users, MyZone employs 
cryptographic methods as well as a certificate authority so that only users within a zone may 
participate in that zone. We show through the description of our design as well as the evaluation of 
a real world deployment of our prototype application, that such a trust-based decentralized system 
can be designed to support standard social network functions, preserve user privacy, be highly 
resilient to benign failures and malicious attacks, tolerate high mobile chum, and achieve these 
objectives while conserving resources. 

The challenges that we face in achieving the design goals of MyZone span six key areas, 
namely trust, availability, resiliency, routing, connectivity, and resource efficiency. In this paper, 
we will focus primarily on the areas of trust and availabiUty, but mention the other challenges later 
in this section. 

3.1 Trust Model 

The trust-based challenges introduced by our private social network concern identifying and main- 
taining the different levels of trust encountered within the system. A user will form a relationship 
of trust with one or more friends. In this case, the user U can write on the social network profiles 
of each of his/her friends, and each of his/her friends can write on user t/'s profile. Within user 
U's friends, certain friends will be trusted even more to act as mirrors in case user U's own devices 
are unavailable to receive profile updates, e.g., posting to U's wall. In this case, the mirrors will 
absorb these update requests, and then re- synchronize with user U when user U is reconnected to 
the network. In fact, we need to distinguish between five levels of trust in MyZone: 

• Trust as a friend: User A trusts user B as her friend and gives B read and write access to her 
profile. This trust is symmetric but not transitive. 

• Trust as a mirror. User A trusts user B as her mirror and grants B permission to serve as 74's 
mirror whenever A is unavailable. User A already trusts S as a friend, hence, this is a stronger 
level of trust. 

• Trust as a replica: In this scenario, user y4 is a friend of user C and user 5 is a mirror for user C. 
User A trusts user B to act as a benevolent mirror on behalf of user C whenever C is unavailable. 
This kind of trust can be referred to as "trust by proxy" and it is in a way, derived based on a 
transitive relationship on "trust as a friend" and "trust as a mirror". One important property of 
this type of trust, is one directional read and write access, i.e., only A can read from and write 
to C's replicated profile on B, and B cannot modify or read A's profile. 

• Trust as a certificate authority: Users put their utmost trust in CA to act as a certificate authority 
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for the private social network. The CA issues certificates to all participating users, and users can 
verify all the certificates that are issued by the CA. 

We assume that the is not penetrable by malicious nodes, while it can be the target of other 

attacks. Also, the CA will never act maliciously during its lifetime. These assumptions are 

essential for the OSN to function. 
• Trust as a user. User A can verify the identity of user B. This can be done through a certificate 

issued to B by a certificate authority (CA) that is trusted by A. 
We need to preserve these levels of trust in the face of a variety of security threats. We consider 
three types of adversaries that may be present in the system. First, some users may be "honest but 
curious" who want to view the user profiles of non-friend users. Second, there may be maUcious 
entities that are not users of the private social network, but want to attack the system in any of 
the following ways: eavesdropping; spoofing; (distributed) denial of service; IP or URL filtering; 
and backtracking, which is an attempt to link some content to a user, e.g., a government agency 
trying to find the user who is responsible for posting some particular content. Third, there may 
be insider threats from malicious users who are part of the private social network. In general, 
malicious entities have two motivations, namely to gather information about users and use it against 
individuals or the social network as a whole, e.g., implementing a divide and rule policy among 
users by spreading mistrust, and to prevent access to the social network, and hence, create an 
outage to a subset of the system. 

We assume that two friends will not act as adversaries of each other. This does not apply to 
friends of friends, since trust is not transitive. We also assume that a benevolent mirror is trusted 
with the integrity of data (it will not maliciously modify the data) but it may act to gain profile 
information from its clients, i.e., mirrors can be "honest but curious" users. 

We will therefore seek a design that prevents the disclosure of profile information to any user 
who is not a friend. A user profile can only be viewed and modified by her friends. MyZone is 
designed to be resilient against DDoS attacks and URL/IP filtering. Also, every modification of a 
user profile is authenticated. 

3.2 Availability Challenges 

An important property of OSNs is that a user profile is always available regardless of whether 
that user is currently online or not. In MyZone, we seek to preserve this property by employing 
mirroring of a user's profile amongst a user's trusted friends. We assume that a user selects friends 
based on social trust via out-of-band discussions. Under these conditions, our challenges include 
the following: 

1. When and how profile updates are propagated to other mirrors. 

2. How to maintain replica consistency among all mirrors. 

3. What type of replica consistency is appropriate for this application. 

4. Whether a user profile is completely or partially replicated at different mirrors. 

5. Whether the mirrors themselves should be prioritized as primary, secondary, and so on. 

6. How many mirrors are needed for a desired level of availability? 

MyZone is designed so that user profiles are "almost always" available. A weakly consistent 
view of the profile is always available. Given the amount of mobile chum, we felt that the con- 
sistency and availability guarantees should be best effort, as the benefits gained through absolute 
availability and total consistency are not worth the added complexity in the design of the OSN. 
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3.3 Other Challenges 



A variety of other challenges remain, including networking and resource challenges. We face some 
practical engineering challenges in terms of the network, such as the fact that many users may have 
their profiles hosted on peers that are positioned behind different NATs, i.e., full cone, address- 
restricted cone, or peer restricted cone. To bridge these connectivity challenges, we introduce a 
relay server into the architecture, as described in the next section. In terms of resource challenges, 
many users' primary devices may be mobile, which are resource-constrained. A challenge is to 
develop a replication strategy that takes into account these limitations while providing availability 
and resiliency. One strategy is to leverage more resource-rich devices, i.e., online desktops, to 
support the bulk of mirroring duties, and to use mobile mirroring only as a strategy of last resort. 
Heterogeneity of device resources and their limitations call for mirroring strategies that take into 
account the limited and diverse memory, bandwidth and energy of the various peers comprising 
the private social network. 

4 System Design Architecture 

My Zone's design is based on a two layered architecture. The lower layer referred to as the service 
layer provides essential services to the components of the system and facilitates the registration 
of peers, finding peers, establishing connections between peers and much more. The upper layer 
is referred to as the application layer. This layer provides standard social network features such 
as wall postings, etc. In addition, it is responsible for implementing higher level security policies 
such as read and write permissions for particular users or groups of users. Profile replication is 
also done at this layer. 

4.1 Service Layer 

Figure |2] illustrates the major steps in terms of how My Zone establishes connections between 
peers using the rendezvous server and a certificate authority. The sequence of steps for each peer 
is represented as i.x where i is the peer and x is the step. Each new user needs to first obtain 
a certificate from the CA server, which verifies that the usemames are unique. We assume that 
peers have already obtained the public key of the CA which is needed to verify the certificates. 
Then, when peers come online, they need to securely register with rendezvous servers in order to 
be discovered by other peers. When a peer comes online and wishes to find a friend, they securely 
query the rendezvous server to find the address of the friend in order to connect with another peer. 
Recall that the rendezvous server is completely trusted in the model of a private social network, so 
it is appropriate for it to know the addresses of the peers within its zone. Two other components, 
namely a STUN server and a set of relay servers are also needed to deal with NAT connectivity 
issues. Our architecture handles attacks on the rendezvous server by periodically synchronizing the 
rendezvous server database with sever other backup rendezvous servers that are all concurrently 
online and available. Any DDoS attack on a rendezvous server is handled by changing the IP 
address of the server under attack and spreading the IP address to all users through the backup 
rendezvous servers. The rendezvous servers essentially collaborate with each other to create a 
dynamic decentralized server. 
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Rendezvous 



2.3: Register with Rendezvous; 2.4: Locate Peer 1 



1 .3: Request Relay 

1.5: Register with Rendezvous 

1 .8: Locate Peer 2 

L 





Virtual connection from peer 2 to peer 



Peer 1 



1 .9: Send Request to Peer 2 (UDP hole punching) 



Peer 2 



Figure 2: Deployment diagram for a private social network. 



The service layer provides an infrastructure that is resilient against partitioning, reliable even 
on top of UDP, and secure against malicious attacks. It is also very dynamic and can be used 
by peers behind all kinds of firewalls and NATs. In this section we describe the service layer 
by describing its components and their interactions with each other. For the sake of brevity, we 
focus our discussion on the two major steps of the protocol, namely registering a peer and locating 
another peer. Details of other steps of the protocol, such as obtaining a vahd CA-signed certificate, 
registration of the relay servers with the rendezvous server, the involvement of the STUN server, 
etc. can be found in our technical report [HI. 
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Peers need to be able to register with a rendezvous server in order that other peers can find them 
and establish a P2P connection. The first message is sent by the peer and includes the peer's cer- 
tificate, while the reply carries the session key generated by the rendezvous server, and encrypted 
by the public key of the peer. If the session key is correctly retrieved by the peer, it sends the fol- 
lowing encrypted information to the rendezvous server: the priority of the device being registered 
on behalf of the user since a user may use several of her own devices as a method of self replication 
on the system; port number; type of NAT, e.g. full cone, non-full cone, or public IP address; type 
of protocol (TCP or UDP); IP address; relay server address and port if needed; a list of passphrases 
generated by the peer for each friendship that are unrelated to actual usemames but are used in 
lookup queries for each peer (known only to the peer's friends); list of mirrors of a peer includ- 
ing the usemames of its mirrors, which are implemented at the application layer as shown later; a 
signed message digest over the following information: IP address, port number, type of protocol, 
relay server address, relay server port and the list of passphrases to ensure the authenticity and the 
integrity of the data sent back by the rendezvous server; and a signed message digest over the list 
of mirrors. 

The rendezvous server will store all this information in its database. Upon successful regis- 
tration with the rendezvous server, the server returns a peer_registered reply along with an 
optional list of pending friendship requests. The friendship requests for peer i are stored in form 
of friendship requester's usemame, and a passphrase specifically generated for i encrypted using 
the public key of peer i. Encrypting the friendship requester's passphrase for i is mandated based 
on a need to know basis, and prevents malicious entities, from looking up the IP address of the 
friendship requester, by providing the passphrase. 

Peer i can look up the connection information for peer j, if 1) peer j has already registered with 
the rendezvous server and, 2) peer i has a passphrase with peer j. A lookup query will first establish 
a secure connection with the rendezvous server, retrieving a session key. After the session key is 
retrieved, the peer sends the passphrase of the target peer to the rendezvous server. Upon finding 
a usemame corresponding to that passphrase in its passphrase table, the rendezvous server replies 
with the connection information of the target peer. The information includes the signed message 
digest described earlier, which will be used by the peer to verify the integrity and authenticity of 
the reply. 

Once the IP address information of the other peer is retrieved then the peers can exchange 
signed encrypted messages with one another, traversing NATs as needed ||9l. 

Additionally, the service layer provides a method for a peer to send friendship requests for other 
peers. All friendship requests for a particular peer x are sent to the rendezvous server, instead of 
sending them directly to x. There are two reasons for this. First, peer x might not be online at 
the time of sending the friendship request and therefore may not receive it. Second, all friendship 
requests do not necessarily end in friendships and the connection information of peer x should not 
be revealed to other peers unless x has accepted their request and has a shared passphrase with 
them. Due to space limitation we refer the reader to [9J for a complete description of sending a 
friendship request. 

4.2 Application Layer 

While the service layer is designed to overcome resiliency, connectivity, routing and most of secu- 
rity challenges 1,9], the application layer needs to tackle availability, traffic optimization and power 
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Caption: 
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Profile Information 



First Name: Richard 
Lost f4ame; ttan 
Gender: l^aie 
Diate Of Birth: 
Relaitlonship Status: 
At>Dut frie; 



Education History: 



Employimnt History: 



Institution: Department of Compiiter 
Science at Tine University of CoioratSo 
at Boulder 



Messages 



Allreza Mahdian: This is my first 
message. 



Created By: Allreza Mahdian 
Title: My first event 
4 I Location: stein's lab 

Start Date: 6/4/201 2 8:00 PM 



Figure 3: A snapshot of My Zone's client application. 

management challenges. The application layer of My Zone is implemented on top of the service 
layer and provides the following functionalities: 

1. Implementing all the social networking features of My Zone: Users can post links, status up- 
dates, video and audio files, and photos on their own or their friends' profiles. Any post can 
be deleted depending on the permission policy in place for that post. Users can comment on, 
like or dislike any post. Users can create events and invite their friends. Users can send private 
messages to their friends. Users can assign their friends to customized Zones and share items 
with them exclusively. The My Zone application UI is shown in Figure [3] 

2. Enforcing permission policies defined by users, for different elements of their profiles: These 
policies define read, write, or no access permissions, for each element of the profile. The user 
may define these access permissions, per individual, or groups of users. This is very similar to 
the concept of access control deployed in operating systems. 

3. Profile replication on other devices to increase availability. 

4. Finally, if a user agrees to serve as mirror for a friend, the application layer needs to support the 
first two functionalities for the mirrored profiles. 

The MyZone user client is written as a cross -platform Java Web application, so it can be 
widely distributed on many platforms. Social network profile information and updates are stored in 
platform-independent XML format. In MyZone, every piece of information is mapped to either an 
attribute or an element. This enables MyZone to support several client applications with various 
features and interfaces tailored to user specific requirements on the same social network. Each 
queryable piece of information has an id attribute that is unique and corresponds to the timestamp 
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of the creation of that element. To achieve fast queries, each element is stored in ascending order 
in its corresponding XML file based on its id. Furthermore, to bound the time of a query each 
XML file only stores a limited number of elements determined by an attribute as part of the client 
application's settings. When querying for a particular element first the correct XML file is loaded 
into memory and then searched for the element with the correct id. Finding the correct file is done 
using a history log that keeps track of three items for each XML file: The id of the very first ele- 
ment stored in that file, the id of the very last element stored in that file and finally the number of 
items stored in the file. The history log itself is stored as an XML file as well. 

To conserve traffic, the application layer uses a pulling scheme to distribute updates among 
users. This means that if two users A and B are friends with each other, A's client application 
periodically tries to estabhsh a connection to a device that is hosting B's profile and upon success- 
ful connection, download the latest profile updates of B onto A's device. Upon every successful 
update session on B's profile, A's client application records the timestamp as the last update time 
for B. In order to optimize traffic, each update session for 5's profile initiated by A's client appli- 
cation will be preceded by A's client application sending out the last successful update time for B's 
profile to B's hosting device. The hosting device would then compute B's latest profile updates 
for A by combining all the updated elements of B's profile since the last successful update time 
at A's client application in a temporary XML file and sending it to A's client application. This 
method minimizes traffic as each piece of profile update is transmitted as part of one and only one 
successful update session per friendship. 

Avoiding retransmission of profile contents for each friend comes at the cost of storing friends' 
profiles locally. This means that at some point the client application may run out of storage for 
friends' profiles. As a measure to avoid this, the client application would store each of friends' 
profiles under a directory named after each friend's username in another directory appropriately 
named as friends. The friends directory has a restricted size, set as part of the client application's 
settings referred to as cache size. The application layer would fill the friends directory with friends' 
profile contents until the cache size capacity is reached. At that point, the latest profile updates 
will replace the oldest profile updates stored in the friends directory. Any deleted content can be 
retransmitted upon request. Therefore, there is a tradeoff between the storage and the traffic: as 
the cache size shrinks the amount of traffic due to retransmission of deleted profile content would 
increase. 

Users can assign their friends to customized Zones e.g. friends, family, colleagues etc., and 
share items with them exclusively. These zones can be overlapping which means a friend can be 
assigned to several zones. When a friend is added, the client application automatically adds the new 
friend to a default zone called All. For every content a user posts on her profile, the corresponding 
XML element has a sharedWith attribute that implicitly dictates the read and write permissions of 
other friends for that content. Unless the content is shared with All zone, it will be only visible to 
members of the zone it is shared with. Furthermore, each posted content can be liked, disliked, or 
commented on by members of the zone that it is shared with. This feature provides more privacy 
to MyZone's users at the cost of more complexity especially when it comes to sending the latest 
profile updates to a friend X, in which case of all the latest profile updates, those that are only 
visible to X should be sent back. This task is the most computationally intensive part of the client 
application. 

The application layer increases profile availability when the cUent application is not connected 
by employing replication. MyZone employs a trust-based replication scheme that will replicate 
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user profiles on two classes of devices: devices that belong to the profile owner and devices that 

belong to friends of the profile owner. The replication on the first set of devices is referred to as 
self replication while replication on the second set of devices is labeled as social hosting. Social 
hosting is the concept of a friend accepting to be a mirror for another friend based on her social 
ties with the original profile owner. 

Social hosting is not forced onto friends. This means that a friend may or may not accept to 
be a mirror for another friend. This may cause a user not being able to obtain a mirror amongst 
her friends. In addition, a friend may limit the amount of storage he is willing to allocate as a 
mirror referred to as mirroring capacity as part of the mirror setting at any time. In this case a user 
may use self replication to increase the availability of her profile without any constraints until she 
can find an appropriate mirror. Self replication is done by assigning a priority to each device the 
user owns. If a user owns a desktop, laptop and tablet/smartphone, then the user can use all three 
devices to host her profile, assigning the highest priority or rank to the desktop, while making the 
laptop secondary and the tablet her tertiary device. All requests to the user's profile are handled by 
the highest priority connected device. 

The rank of the device is generaUzed to social hosting as well. When a friend Y of user X 
agrees to mirror for X, X will give a rank to Y . This rank can be a mixed function of X's social 
tie with Y , the resources that Y is allocating to mirror for X, and F's connectivity. While X's 
devices are offline the requests for X's profile are sent to her mirrors starting at the highest rank. 
This means that if a higher ranked mirror is available the lower ranked mirror is not going to be 
used. 

After Y has agreed to be X's mirror the most recent profile contents of X will be sent to 
F's device as part of initial synchronization. In case X's profile size is larger than the allocated 
capacity by Y, the mirroring space on Y is filled with the latest contents from X's profile and the 
old contents are not replicated. Upon successful initial synchronization, X would send out y s 
usemame and its mirroring rank as part of its registration information to the rendezvous server. 
The rendezvous server will store this information in its mirrors table. This information will be 
distributed to all of X's friend the next time that any of them tries to locate X. 

When a friend of user X labeled as Z tries to connect to X's profile it will send a locate 
peer query to the rendezvous server with priority value of to connect to X's primary device. 
Upon receiving the connection information, Z tries to connect to X's primary device. In case X's 
primary device is unreachable Z sends out a locate query for X's secondary device by incrementing 
the priority value by one and repeats this process for the tertiary device in case the secondary device 
is also offline. Note that in our design we have limited the self replication to only two devices which 
means that a user can only have three devices associated with her MyZone profile and while a user 
must have a primary device, having secondary and tertiary devices is optional. When all three 
of X's devices are unreachable, Z can get the most recent profile updates of X from her mirrors 
starting at the highest ranked mirror. To locate user X's rank i mirror, the value of priority sent as 
part of locate peer query is computed as i + 2 where the offset by 2 is indicating that the device is 
a mirror. 

The application layer is realized as three major components: MyZone Engine, Web Applica- 
tion, and shared classes. The MyZone Engine is the most crucial part of the application layer. It 
runs as a background process and is responsible for downloading all the latest profile updates from 
friends, sending out all the contents posted by the user on friends' profiles, synchronizing with 
other replicas, and finally managing the storage capacity based on the limits set in the application 
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setting. It is essentially responsible for all the P2P transmissions as well as storage management. 
It consists of two threads. A client thread periodically pulls the latest profile updates from other 
friends, sends out postings on other friends' profiles, and periodically synchronizes the user's lat- 
est profile updates with her mirrors. This is done by first receiving all the latest updates from the 
mirrors starting at the highest ranked mirror, merging those updates with the current profile and 
finally, sending out the updated profile to the mirrors. A server thread receives requests for profile 
updates from a friend, and generates the correct delta update to that friend. This involves bundling 
all the latest profile changes based on their shareWith attributes and the requester's membership in 
different zones. The serving thread is also responsible for receiving and storing the updates posted 
by other friends on the user's profile. Upon receiving a synchronization request from a mirrored 
profile owner, the serving thread is responsible for sending back all the latest updates of the mir- 
rored profile and receiving the latest version of the mirrored profile from the original user. The 
serving thread handles received requests for mirrored profiles as well as storage management of 
both friends' directory and all the mirrored profiles. 

The Web application component of the application layer is responsible for representing all the 
information stored on XML files to the user through Web interfaces. The Web application layer 
includes a Java based web server to provide the web interfaces. To convert XML files into Web 
pages we use JavaServer Pages (JSP) technology. The JSP code uses the classes in the shared 
class component of the application layer to convert XML files into Web pages. The user can view, 
modify or create new content using the Web interface. Finally, the shared classes component is 
composed of a set of classes used as a toolbox by the other two components to convert the data 
between XML files and Java classes. 

5 Evaluation 

We have implemented a fully-featured application that was evaluated using both real-world de- 
ployment and emulation. Our evaluation focuses on three key aspects: profile availability, resource 
utilization, and scalability. 

We ran a local deployment of My Zone for 40 days for a closely-knit community of 104 users. 
Being in a closely-knit community, almost all the users were friends with one another. We pro- 
vided a rendezvous server, and a STUN server for the experiment in addition to 20 relay servers 
each capable of handling 20 concurrent connections. Client applications were configured to regis- 
ter with the rendezvous server every 2 minutes and send their logs to the rendezvous server at the 
time of registration. For each interaction initiated by a client the application created a single line 
in the log file that included the following information: Session start time. Action type (posting and 
updates). Target friend (target friend's user name). Serving friend (user name of the user hosting 
that friend's mirror). Data size. Session status (Connection established/not established, success- 
fully/unsuccessfully received updates, and successfully/unsuccessfully sent posts), and Session 
end time. 

Table [T] shows the geographical and timezone distribution of the 104 users. Before the start of 
our experiment, we provided a video tutorial of My Zone to all users and also gave them a 5-day 
grace period to set up their basic profiles and add friends. The social graph was almost complete 
with 5117 edges and 104 nodes. In order to evaluate My Zone under realistic loads we asked all 
users to duplicate their Facebook interactions on MyZone for the duration of our experiment. We 
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Table 1: Geographic and Timezone Distribution of the Users. 
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also asked all users to create different zones if they wanted to and set the value of refresh interval 
for each zone based on their experience on Facebook. The average refresh interval reported by the 
users was 30 minutes which meant that most of the users expected a new entry in their news feed 
approximately every 30 minutes. 

93% of the users were behind symmetric firewalls which meant that they had to use our re- 
lay servers in order to receive connections while the remaining 7% used routers that supported 
UDP hole punching. We recorded 200GB of traffic relayed over our servers over the duration of 
our experiment. Also, in order to measure the resiliency of My Zone against DDoS attacks on the 
rendezvous server we brought down the rendezvous server at the end of the 35th day of our exper- 
iment. Therefore, in the last 5 days of our experiment the client applications did not have access to 
the rendezvous server to locate their friends. 

5.1 Availability 

Availability provides a measurement of how often a user profile is available. A user profile is 
available when the machine that is hosting the profile is connected to the network. We compute 
average daily availability over the first 35 days, i.e., when the rendezvous server was available. 
More specifically, we consider update sessions (i.e., receiving profile updates from friends) and 
posting sessions (i.e., posting contents on friends' profiles). We define success ratio as the ratio of 
the number of successful sessions to the total number of sessions. Since each failed session results 
in a sequence of retries, we count a failed session and all of its consecutive retries only once to 
avoid overestimation of failed sessions. 

Figure|4] shows the average success ratios of update and posting sessions for a day. The success 
ratios for both posting and update sessions are close to 90% (89% for posting sessions and 92% for 
update sessions). Success ratios were lower (still above 75%) in the early hours of the day, when 
most users were offline. The success ratios for update sessions show smaller variations than those 
for posting sessions, since the number of update sessions is much larger than the number of posting 
sessions and the impact of failed sessions is relatively smaller. Figure [5] shows the daily success 
ratios for the entire duration of our experiment, which were consistently high for the first 35 days. 
Even for the last 5 days, when the rendezvous server was brought down, the drop was not very 
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Figure 4: Trend of average success ratios of update and posting sessions for a day. 
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Figure 5: Trend of success ratios of update and posting sessions for the entire duration of the 
experiment. 

steep: down to 75% for update sessions and 65% for posting sessions. This shows that My Zone 
continues to be operational even when its centralized server (rendezvous server) is brought down 
by adversaries. Also, the average success ratios for the entire duration of our experiment are 89% 
for update sessions and 87% for posting sessions. 

Availability naturally depends on the number of devices and mirrors each user has. Figure [6] 
shows the distribution of the number of devices and mirrors for the users. Approximately 90% 
of the users were able to obtain at least one mirror, while around 20% had a secondary device 
available in addition to a primary device. Our results indicate that it was fairly easy for most of 
the users to obtain one mirror while obtaining more mirrors becomes harder. Note that mirroring 
in our design is purely based on the willingness of other friends and the strength of social ties 
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Figure 6: Number of users based on their number of mirrors and devices. 
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Figure 7: Average success ratios of sessions over a day for different groups of users based on their 
number of mirrors and devices. M, D, and N denote the number of mirrors, devices and users 
respectively. 

between the users impacts this willingness a lot. That is why we refer to this method of mirroring 
as social hosting. 

We categorize the users into different groups based on the number of their devices and mirrors. 
Figure |7] shows the number of users in each group as well as the average success ratios (of the 
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Figure 8: Average success ratios of sessions over the entire duration of the experiment for different 
groups of users based on their number of mirrors and devices. M, D, and N denote the number of 
mirrors, devices and users respectively. 

first 35 days) for all sessions targeted for users of each group over a 24 hour period starting at 
midnight. As expected, users with more mirrors and devices have higher profile availability. But 
the additional gain in the availability does not increase linearly with the number of mirrors and 
devices. Based on our results 1 mirror and 2 devices seems to result in optimal availability. 

Figure [8] shows the daily success ratios of all posting and update sessions for each group of 
users. We see that most of the groups maintained high availability. During the last 5 days, when 
the rendezvous server was down, the success ratios of users with 1 mirror and 2 devices is second 
only to those users with 4 mirrors and 2 devices. A careful analysis of the log files revealed that 3 
of the users belonging to this group have the same mirror which did not lose connectivity during 
the last 5 days and hence it had the same connection information and therefore, even though the 
rendezvous server was out, user profile for those three users were always available through that 
mirror and hence the high overall success ratios for that entire group. Another observation is that 
the success ratio of the users with no replicas would drop to almost 0% when the rendezvous server 
was down. 

We further consider the proportion of sessions that were handled by the mirrors instead of the 
user devices. We compute the impact ratio, which is the ratio of the number of sessions handled 
by mirrors to the total number of sessions for each group of users based on the number of their 
mirrors. As shown in Figure |9} having one mirror has around 32% impact on profile availability 
while having 2 mirrors increases this number to 42% which means that a second mirror results in 
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Figure 9: Average impact ratio of the availability of users based on their number of mirrors over 
the entire duration of the experiment. 



1 

0.8 

o 

V 0.6 
rj 
C& 

tJ 0.4 
o. 

1 0.2 





Device impact ratio 
























1 


1 



1 2 
Number of Devices 



Figure 10: The average impact ratio of the availability of users based on their number of devices 
over the entire duration of the experiment. 



around 10% increase in the overall profile availability. As for more than two mirrors the added 
availability is very small so we can conclude that there is an optimal number of mirrors based 
on the profile availability gained and in our experiments it is 2. This number is a function of 
the overlap in terms of connectivity times of mirror devices and the mirrored user as well as the 
duration of their connectivity. In other words selecting mirrors that are mostly online during times 
that the original user is offline would decrease the number of mirrors one requires to have most 
profile availability. 

The important outcome from Figure|9]is that choosing the right mirrors is more important than 
the number of mirrors. This was illustrated by the fact that the added advantage of having more 
than 2 mirrors in our experiment is very little. 

Finally, we show the average impact of primary and secondary devices on profile availability 
in Figure [Toj As we can see, a second device would result in 20% more impact on the availability, 
which is quite good considering that a single device results in 60% impact ratio. This shows that 
even if users can not obtain a mirror, having additional devices would have a significant impact 



17 



20 

17 r 

15 



Number of users 




oooooooooooooooooooooooooo 
oooooooooooooooooooooooooo 
LnuDr~voo<T!0'Hrsiro'^Lnu3r^oo<T)0'H<Nrn'd-Lnvx)r-voo<TiO 

iH^HTHiH^HTH^HvHTH^HfNjfN<NrNlfNrNjrNl<N(NrNlrri 



Figure 11: Histogram of the number of users with respect to the mirroring storage capacity they 
are willing to allocate. 

on their availability. Of course when a user replicates her profile on several devices, these device 
connectivities are usually non overlapping. This means when one is connected the others are 
usually offline and overall this would increase the effectiveness of self replication. 



5.2 Resource Utilization 

In My Zone, if a user chooses to be a mirror for another friend, her resource consumption will 
increase. This increase will generally be related to the number of friends and profile size of the 
mirrored friend. We analyze the storage and bandwidth requirements of My Zone client application 
related to mirroring. The bandwidth requirement of MyZone for a user profile will be analyzed 
later as part of scalability. 



Figure 11 shows the histogram of the number of users willing to be mirrors based on the 
storage that they are willing to allocate for mirroring. This figure shows that most users are willing 
to allocate 500 MB to 1500 MB of disk space to mirror their friends, which is quite low compared 
to the size of a typical hard drive. 

Next, we measure the actual size of the profiles stored on each mirror. Figure [12] shows the 
cumulative distribution of the number of mirrors based on the size of the mirrored profile. It 
indicates that most of the mirrored profiles occupy 3MB to 23MB of storage, and very few have 
much larger sizes. In fact 95% of the mirrored profile sizes are less than 73MB. This implies that 
the amount of disk space users are willing to allocate for mirroring is a significantly larger than 
the actual amount of storage needed for mirroring. Our results show that the tendency to allocate 
much larger stirage space for mirroring has strong correlation with self identified social ties among 
users. This indicates that users are not stingy when it comes to allocating space for mirroring 
people whom they have strong social ties with. 

Next, we computed the ratio of the traffic generated by all mirrors of a profile to the size of 



the profile for all 94 mirrored profiles. Figure 13 shows the ratios sorted in increasing order. The 



ratio of traffic to profile size for a mirrored user x roughly indicates how many of x's friends have 
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Figure 13: The growth trend of traffic to used storage ratio for mirrored profiles. 

used the mirror to interact with x. The graph indicates a linear behavior, where the ratios start 
at just over 1 and grow to just under 75. We investigated our log files and realized that this ratio 
is largely a function of the availability of the original user and the rank of the mirror (as will be 
discussed later) than anything else as almost all of our users had the same number of friends. Since 



the average number of friends in our social network is 98, we can conclude from Figure 13 that a 
mirror is responsible for handling the requests of approximately 35 friends of the mirrored user. 
This is because the total traffic to profile size should be equal to the number of friends for each 



user. This is due to the optimal traffic generation of MyZone as described in 4.2 Therefore, in 
total, mirrors are responsible for nearly 35% of the total traffic in our experiment. 
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Finally, we have evaluated scalability aspects of My Zone based on cpu utilization and applica- 
tion response times. Due to space limitations we will not be able to present our results in details. 
However, our evaluation based on emulation of clients with up to 1600 friends indicate that the 
My Zone client application can easily accommodate over a thousand friends per each user while 
the response time and the cpu utilization never exceed 500ms and 70% respectively. The typical 
number of friends on popular OSNs is expected to be much lower [fT4ll . 



6 Conclusion & Future Work 

To our knowledge. My Zone is the first OSN with the following properties. It preserves user pri- 
vacy by storing user information on their own devices and replicating them on a number of other 
devices belonging to trusted friends. It is secure based on a "need to know basis" philosophy and 
aU connections are encrypted. It is resilient to benign and malicious attacks. The private social 
network model can be set up conveniently and quickly to construct a private OSN for a limited 
number of users. It is backward compatible and a wide variety of client applications with different 
user interfaces and features can coexist while users can choose the applications that fit their needs 
and preferences. We proved the feasibility of such a system by implementing the service layer part 
to support a private social network and a sample client application that supports common features 
of a conventional OSN. We presented detailed experimental results that analyze availability and 
resource utilization metrics for a deployment with over 100 users. 

We plan to develop a mirror recommendation system that selects the most appropriate friends 
as mirrors. This is a twofold problem, namely how do we select friends that results in maximum 
availability, and how do we incentivize friends to accept being mirrors given limited resources? 
Providing the minimal incentives while increasing the chances of acceptance is analogous to the 
problem of bidding in online auctions. We also plan to extend MyZone to a large scale public 
deployment and have built a Web site for public release [4] . We intend to support more mobile 
platforms as well, e.g. iPhone. 
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